Repository navigation
fix(devex): keep the admin console audit log at info - #131086
Conversation
The posthoganalytics SDK claims the "posthog" logger name and clamps it to WARNING. The console writes its audit lines (operation started/finished, with the actor and the reason staff gave) at INFO under posthog.admin.console, so none of them reached the logs. Give the console package its own INFO level, the same way other INFO diagnostics under posthog.* already do. Found by Dan Marchuk in #130856.
|
😎 Merged successfully - details. |
|
Risk: No findings This PR adds an explicit INFO logging config for Sentinel reviewed |
🤖 CI report
|
Master landed its own tool operations (#130715, #130716) while this branch built an inline version of the same thing. Master's design wins where both built it: - ToolOperation, its handler protocol, the operation page at /tools/<tool>/<op>/, gate, preview via ConfirmStep and the signed token, and result pages all come from master. The inline OperationForm block, _fill_operation_forms and the POST path in tool_page are dropped, so tool pages stay read-only (@require_safe). - check_danger replaces check_danger_contract. - Live replaces Page.refresh_seconds and the meta refresh in base.html. - posthog/settings/logs.py takes master's version; the audit log level fix lands in #131086. Kept from this branch, adapted to master's block rendering (_block.html): - Filters (GET form, field groups and their contract check), Stats/Stat, Links/Link, Notice.tone (callout, now also shows the notice link), Table.title/numeric_columns/scrolls, Cell.detail - data-pending-label loading labels in console.js - the "Incidents" tool group - Live can hold a Stats block too, so a status row can follow running work Tests: the inline-operation cases now hit master's operation URL, which keeps coverage master lacks for tool operations (offered lookup, query kept on redirect, refusal re-renders the form, CSRF). The ToolOperation danger and Filters contract cases stay. AGENTS.md and the extending-the-admin-console skill describe master's operation model plus the new blocks. console.css rebuilt.
![stamphog[bot]](https://avatars.githubusercontent.com/in/3000332?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approved.
The audit-logging change has current-head independent review with no findings. No unresolved substantive concerns or other refusal grounds are present.
- Author wrote 0% of the modified lines and has 43 merged PRs in these paths (familiarity MODERATE).
- PostHog Review (Standard) reviewed the current head: no findings.
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 2L, 1F substantive — within ceiling |
| tier | ✓ | T1-agent / T1a-trivial (2L, 1F, single-area, fix) |
| stamphog 2.7.0 | .stamphog/policy.yml @ bc901c6 · reviewed head bc901c6 |
Problem
/admin/console/) leave no audit trail in the logs. The console writes who ran which operation and the reason they gave at INFO, but theposthoganalyticsSDK clamps theposthoglogger to WARNING, so every one of those lines is dropped.Changes
posthog.admin.consolelogger gets its own INFO level, like the other INFO diagnostics underposthog.*insettings/logs.py.How did you test this code?
django.setup()with the SDK loaded:posthogstays at WARNING, andposthog.admin.console.viewsandposthog.admin.console.organization_toolsare enabled for INFO.Release status
Docs update
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Agent: Claude Code, claude-opus-5-5
Skills:
/writing-pr-descriptions